1. Field
The invention disclosed and claimed herein generally pertains to a system and method for creating and revising a network object graph topology model, or object graph, for a network. More particularly, the invention pertains to a system and method of the above type which is generally applicable in any domain wherein entities of the network are modeled as resources that have attributes and there is a desire to arrange the resources into an object graph. Embodiments of the invention could be used with network performance management systems and social media applications, as representative examples, but the invention is not limited thereto.
2. Description of the Related Art
Network performance management involves measuring, modeling, planning and optimizing networks. This is done to ensure that a managed network carries traffic with a speed, reliability, and capacity that is appropriate for a particular network application, and is also appropriate for the cost constraints of an associated organization. In order to perform these functions effectively for a given network, a performance management system must first collect data from many different sources in the network, and then generate statistics from the data and use the data to produce reports. These activities, which may be referred to as analytic processing, provide results which include basic summary statistics such as aggregations. Results may also include Busy Hour data, which indicates when network components experience their heaviest traffic loads.
Before a performance management system can collect or gather data of the above type, it must first discover the devices or resources that are included in the given network. Resources are exemplified by devices such as web servers, application servers, and routers, but are not limited thereto. In one approach, a performance management system uses available heuristics and algorithms to scan the network, in order to detect the respective devices contained therein. Alternatively, the system may initially be provided with a set of data that shows all the resources included in the network.
After all network resources have been discovered or determined, the performance management system typically applies an organizational mechanism to the resources, to arrange the resources into a data structure on the basis of specified groupings related to an intended purpose or objective. Common examples would be to arrange the resources based on their respective geographic locations, or on customer relationships. Usefully, the organizational mechanism comprises a set of organizational or grouping rules, which provide relationships or contexts for arranging respective resources. By applying the set of rules to the set of discovered resources, the management system generates a structure comprising an object model or object graph, wherein network resource instances are nodes on the graph, and relationship instances are arcs or edges on the graph. The object graph may comprise a tree structure, but is not limited thereto. The constructed object graph is then used by the management system for subsequent analytic processing of the given network.
In arrangements of the above type, changes are expected to occur to resources over a period of time. Accordingly, the object graph must be repeatedly updated to accord with such changes. However, present methods for updating an object graph generally use the same type of batch-oriented technique that is used to create or generate the object graph initially for a particular network. In such technique, resources are first placed into a performance management system database. In one exemplary system, known as Tivoli Network Performance Management (TNPM), the rules are transformed into SQL queries. Other systems may use the rules in other ways to provide the queries. The queries are then executed against the global set of resources and existing resource/groups, to determine what resources and relationships should be created or deleted. Thereafter, in order to update the object graph for the particular network, this same batch technique is carried out periodically, at prespecified intervals that are based on the needs or characteristics of the particular network. Thus, the updating batch procedure could, as examples, be run on the network every hour, every six hours, or on a daily or weekly basis. More generally, the objective is to track the network changes closely. If the network changes frequently (which is very common), then a large number of object graph updates will ensue.
A significant drawback of such currently used updating procedure is that the computational effort required to update an object graph can be grossly disproportional to the amount of network change which has actually occurred. For example, a network containing on the order of 106 resource devices could have experienced change to only one or a few of the devices since the last update procedure. Moreover, use of a batch procedure places a very uneven load on the associated system, particularly for large networks. For example, every resource of the network may be affected, each time the updating batch procedure is run.